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REMARKS 



Claims 1-20, 22 and 24 were pending. No claims have been amended, added or 
canceled. Accordingly, claims 1-20, 22 and 24 remain pending subsequent entry of the 
present amendment. 



35 U.S.C. § 103 Rejections 



In the present Office Action claims 1-20, 22 and 24 stand rejected under 35 
U.S.C. § 103(a) as being anticipated by previously cited reference Matic, et al. 
("Predictive Playout Delay Adaptation for Voice over Internet") (hereinafter "Matic") in 
view of U.S. Patent No. 6,622,173 (hereinafter "Luke"). However, Applicant submits 
each of the pending claims recite features neither disclosed nor suggested by the cited art. 
Accordingly, Applicant traverses the above rejections and requests reconsideration. 



Claim 1 recites a packet buffering system for predictively processing data packets 
that comprises: 



". . .direction logic, coupled to said packet predictor, for generating a Packet ID for 
said future packet , wherein said Packet ID is stored in one of said plurality 
of queues; 

buffer logic, coupled to said packet predictor, for accessing said memory and for 
validating said predicted information about said future packet based on 
said access to said memory; and 

a processing core, coupled to said plurality of queues, wherein if said buffer logic 
validates said predicted information, notification is made to said direction 
logic which passes said Packet ID for said future packet to said processing 
core to initiate speculative processing." (emphasis added). 



As highlighted above, claim 1 recites "direction logic ... for generating a Packet ID for 
said future packet, wherein said Packet ID is stored in one of said plurality of queues." In 



7/12 



Application Serial No. 09/935,446 - Filed August 22, 2001 



the present Office Action, the Examiner states "Matic does not disclose the generation 
and storage of packet identification for future/predicted packets . . . Luke also teaches a 
packet prediction system. Luke teaches how predicted packets are represented by a 
Packet ID (equivalent to Luke's PktNum) (column 2, lines 37-59, Luke)." However, the 
PktNum is not a packet ID, but represents the number of packets remaining in a message 
following the indexed packet in the Receiving Message Proxy. Luke discloses these 
features in the following: 



" PktNum represents the number of packets in the prediction associated 
with the checksum . For example, if the receiving proxy 22 receives a 
packet 1000, it predicts the occurrence of Message 2 and transmits a 
checksum, 101, which represents the following 3 packets which are 
stored locally and accessible to the receiving proxy 22 ... In the 
present example, where messages are assumed to comprise 
approximately 5 packets , a three bit PktNum is sufficiently large to 
cope with the number of packets the system is to make a prediction 
about ... In the present example, the second packet of a message is 
chosen as the one on which to base a prediction and the checksum is 
used to predict the remaining packets." (Luke, col. 2 lines 42-59) 
(emphasis added) 



As can be seen from the above example, the PktNum entry in the Receiving Message 
Proxy only denotes the number of packets following the packet being referenced in the 
buffer entry. The PktNum entry is not generated to identify a specific future packet and it 
does not identify a specific future packet. The PktNum value is not unique. Other packet 
entries in the Receiving Message Proxy may have the same value in their PktNum field, 
especially if many messages do have 5 packets as suggested in the above disclosure and 
the second packet is chosen in many cases as the one on which to base a prediction. 
Further, storage of a generated identifier of a future packet is not taught in the above 
disclosure or in the remainder of the document. For at least these reasons, claim 1 is 
patently distinct from the cited references, taken either alone or in combination. 

In addition to the above, claim 1 recites: 
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"a packet predictor ... for predicting information about a future packet 
in any one of the plurality of data flows based on history of 
previously received packets from the plurality of data flows, 
said history stored in a memory coupled to said packet 
predictor; 

... buffer logic, coupled to said packet predictor, for accessing said 
memory and for validating said predicted information about 
said future packet based on said access to said memory " 
(emphasis added) 

In the present Office Action, the examiner states "Nor does Matic teach sending 
verification of the prediction." The examiner further states "... Luke also teaches how 
notifications (equivalent to Luke's checksums) are sent to the transmitting buffer to 
validate the prediction (column 2, lines 18-30 and column 3, lines 29-41)." In Luke, a 
memory for storing a history of previously received packets is the Message Store in 
Receiving Message Proxy 22 of FIG. 3. The Message Store stores the remaining packets 
of a message wherein the message may be constructed earlier than received if it is the 
correct message for the corresponding received packet (i.e. Message 2 may be completed 
earlier when packet 1000 is received in the above example). The Message Store is 
accessed after the checksum is validated in the Transmitting Message Proxy. The 
validation of the predicted information, the checksum in Luke, about a future packet is 
not based on access of the Message Store or history of previously received packets. 
Instead, the validation is based on access of the Transmitting Message Proxy with the 
checksum. For these further reasons, claim 1 is patently distinct from the cited 
references. 

Furthermore, claim 1 recites: 

"a processing core, coupled to said plurality of queues, wherein if 
said buffer logic validates said predicted information , 
notification is made to said direction logic which passes said 
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Packet ID for said future packet to said processing core to 
initiate speculative processing." (emphasis added) 

As shown above, neither Matic nor Luke disclose validation of predicted information in 
the manner recited by the limitations of claim 1. Also, neither reference teaches the 
generation of a packet ID for said future packet. Therefore, the above features of claim 1 
are nowhere present in either reference taken alone or in combination, and claim 1 is 
believed to be patentably distinct from the cited references. Claim 17 is distinguishable 
for similar reasons. 

Finally, the dependent claims recite additional features neither disclosed nor 
suggested by the cited art. As provided in the previous response, claims 6 and 15 recite 
the features: 

"...said packet predictor predicts specific characteristics, comprising 
one or more of packet type, packet flow identification, sender 
information, destination information, and packet size for said future 
packet." 

However, Matic nowhere discloses a predictor that predicts the characteristics listed 
above. Rather, Matic discloses a predictor that predicts the delay jitter of packets. In the 
present Office Action, the Examiner states the above features are disclosed in the 
following portion of Matic: 

"To achieve this goal we need to know characteristics of jitter in 
advance. Hence, main component of smoother on a receiver side is a 
jitter predictor. In this paper we present one of the possible solutions: 
the predictor based on Adaptive Neuro-Fuzzy Inference System." 
(Matic, p. 348, col. 2, paragraph 6). 

Only predicdon of jitter is disclosed above and not prediction of any of the characteristics 
recited in the claim. Additionally', Luke makes no prediction of packet characteristics, let 
alone of the characteristics recited in claim 6. Rather, Luke predicts whether or not a 
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message thai comprises multiple packets may be completed with its corresponding 
remaining packets after a portion has been received. Accordingly, claims 6 and 15 are 
patentably distinct from the combination of cited references for these additional reasons 
as well. 

.Applicant believes all claims to be patentably distinguished from the cited art for 
at least the above reasons. 
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CONCLUSION 

Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. If any extensions of time are necessary to prevent the 
above referenced application from becoming abandoned. Applicant hereby petitions for 
such extensions. 



Respectfully submitted. 



/Rory D. Rankin/ 
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